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(57) Abslracl: A modular interactive 
system and method for customizing 
health education to an individual at a 
remote terminal to induce a modification 
in a health- related behavior of the 
individual. The first step is lo name 
the future pro-am (700). Next, a user 
selects the disease libraries (710) from 
which the program dialogs are created. 
Simultaneously, the user checks the 
Utilities Library (720) lo add dialogs lo 
the program that are not. disease specific 
like generic greetings. Creating ihe 
program is now a simple lask of adding 
dialogs to the program list (730), arid to 
define Ihe delivery of Ihe dialogs (740) as 
a user can choose specific delivery of the 
dialogs on a daily (750), weekly (752). or 
any other (751) programmed timed bases. 



For two-fetter codes and other abbreviations, refer to the "Guid- 
ance Notes on Codes and Abbreviations " appearing at the begin- 
ning of each regular issue of the PCT Gazette. 
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AN INTERACTIVE PATIENT COMMUNICATION DEVELOPMENT 
SYSTEM FOR REPORTING ON PATIENT HEALTHCARE MANAGEMENT 

10 

FIELD OF THE INVENTION 
The present invention relates generally to a modular interactive 
15 development system and method for reporting on patient management, and in 
particular to an automated content delivery program able to connect remote users 
across independent platforms to a central database of libraries whereby a patient's 
health can be scored dynamically. 

20 BACKGROUND OF THE INVENTION 

This invention relates to the Held of health management", particularly to an 
automated interactive system and method for reducing the risk associated with a . 
monitored client. 

For example, the know art includes a number of health-management 
25 systems for providing outpatient services to patients with chronic health 
conditions such as asthma and diabetes. However, these systems are incapable of 
administering a treatment protocol responsive to the patient's current profile and 
of updating the profile in response to the administered protocol. 
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SUMMARY OF THE INVENTION 
This invention presents a flexible and scalable system in content 
development for patient management healthcare. Due to the modular object 
oriented-structure, individual content modules ("dialogs") can be mixed into an 
5 unlimited number of updateable customized programs, addressing individual as 
well, as coexisting disease states ("co-morbid") in any combinations, and with 
automated content variation for improved patient compliance. A dialog is the 
smallest content object in the FlexCube content structure. Its content addresses 
issues related to a unique set of symptoms, behaviors or knowledge related to a 
1 0 specific aspect of managing a certain disease referred to as an aspect of care. 

In its basic format, each dialog contains questions related to signs and 
symptoms, behaviors and knowledge with answers categorized as high, medium or 
low risk answers. For each answer there is a relevant follow up, which can be a 
teaching statement, an acknowledgment, a motivational statement or a new 
question that will explore the patient's condition in more depth. While the logical 
branching within a dialog is driven by patient answers, no dependency exists 
between individual dialogs. 

Dialogs are located in a common pool organized by library. From this 
library each individual dialog is referenced for participation (appearance) in 
programs arid daily sessions. A dialog's behavior in a program (schedule, position, 
reporting) is defined at the time of the dialog creation or it is custom defined 
during the program content selection process. In this way dialogs maintain their 
integrity while being used and re-used in several client programs. They combine 
freely with other dialogs in user defined program selections, allowing an unlimited 
25 combination of aspects of care and co-existing diseases. Finally, they are easily 
accessible for revisions and updates. 

The present invention provides an object-oriented dialog and modular 
toolkit structure that enhances quality control options. Also included are the 
cenirally focated content objects that offer overview and tracking of the currently 
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active content, global error correction and global update of content to current 
standards of care. Because the present invention splits up interfaces for content 
creation and content selection into separate modules, the present invention 
exercises control over customer's access to content development in compliance 
5 with current and future Federal Drug Administration labeling. Finally the system's 
structure limits logical branching errors to within a dialog, thereby offering a more 
robust and less error prone system overall 

Since the content of a dialog and the output of a dialog is related and 
mapped to a specific aspect of care, the user will have the power and flexibility to 
10 model risk evaluation and outcomes reporting around custom selected aspects of 
care. 

BRIEF DESCRIPTION OF THE DRAWINGS . 
The foregoing aspects and many of the attendant advantages of this 
15 invention will become more readily appreciated as the same becomes belter 
understood by reference to the following detailed description, when taken in 
conjunction with the accompanying drawings, wherein: 

FIGURE 1 is a block diagram depicting a system's compositional and 
referenced components; 

20 FIGURE 2 is a flow chart diagram depicting the overview of dialog 

creation; 

FIGURE 3 is a block diagram depicting an interdependent characteristics 
(operators) of a dialog; 

FIGURE 4 is flow chart depicting the steps in creating and storing of 
25 content data from a dialog; 

FIGURE 5 is a flow chart diagram depicting the creation of the 
programming statements using a Dialog Editor Platform; 

FIGURE 6 is a block diagram illustrating the three dimensional aspects of 
the dynamically determined risk state output scale; 

3 * 
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FIGURE 7 is a flowchart depicting the creation of programs using a 
Program Composer User Interface; 

FIGURE 8 is a flow chart depicting a Linker User Interface; and 
FIGURE 9 is a flow chart depicting a Reporter User Interface, 

5 . 

DETAILED DESCRIPTION OF PREFERRED EMBODIMENT 
The present invention includes an object-oriented content structure in 
which the smallest content object, a care specific dialog, is located in a, central 
library from where its characteristics (operators) are composed and referenced by a 
10 modular set oftools located at a client computer. 

FIGURE 1 is a block diagram depicting a system 1 0's compositional and 
referenced components. Compositionally, the system 10 relies on four system 
components for dialog or program creation. Additionally, FIGURE 1 illustrates 
two other system components that interact with the referenced components of the 
system. A dialog Composer 20, further referenced in FIGURE 2, which is used to 
author dialog content by an aspect of care. A Program Composer 30, further 
referenced in FIGURE 7, is a user interfaced click and drag assembly platform for 
composing programs (a virtual content defined collection of dialogs). On a 
computer desktop, content dialogs are selected (referenced) for use in 
disease/client specific programs, with program specific tagging of individual 
dialog attributes related to frequency (scheduling) and reporting. A Program 
Patient Linker 40 is a user interface integrated into the desktop on which patients 
are assigned to programs. During the assignment process patient identification and 
patient.specific metrics are added to the program. A Care Reporter 50, fiirther 
referenced in FIGURE 9, is a user interface for easy patient result lookup, triage 
and trend reports. Reporting requirements set in the Program Composer 30 
determine which reports are displayed. 

Compositional elements of the system 10 reference e.ther one or both of 
the two remaining components of Ihe system depicted in FIGURE 1. A Program 
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Scheduler 60, further referenced in FIGURE 8, is an engine for automated 
scheduling of dialogs based on attributes set in the Program Composer 30, and A 
Dialog Library 70. The Dialog Library is the principal central location of dialog 
content units. Dialogs are organized into body system labeled sub-libraries and 
stored within the Dialog Library 70. 

The structure of the system is developed from the integration of the four 
compositional components as referenced above with the two referenced 
components and begins with the creation of dialogs in the Dialog Composer 20 as 
depicted FIGURE 2. 

FIGURE 2 is a flow chart diagram depicting the overview of. dialog 
creation and is referenced with more particularity in FIGURE 4. Referring to 
FIGURE 2, a patient 100 reports on a specific aspect of care 11 0 (i.e., foot care in 
a Diabetes Structure) .hat is addressed by a dialog 125, the smallest content 
structure of the system, from a disease specific library 120. The basic format of 
each dialog includes questions 130 rela.ed to patient self-management behaviors 
132, patient-reportable symptoms 134, or patient knowledge 136. Each question 
provides a choice for an answer ("output variable") 140 that falls into one of three 
risk categories; high 142 medium 144 and low risk 146. For each risk category- 
there is an associated follow up 150 which is a leaching statement 152, a 
motivational statement 154 or a new question 156 that explores the patient's 
condition in more depth. 

While the logical branching within a dialog depends' on output variables, 
no dependency exists between individual dialogs. Dependencies for dialogs exist 
outside the dialog structure in related operators. 

FIGURE 3 is a block diagram depicting the interdependent characteristics 
(operators) of a dialog 300 in the system matrix. The interdependent 
charac.enstics include a Name Label 310 for .he aspect of care addressed, a 
Library 320 lhat houses a body system specific Localization 325, client specific 
Programs 330 in which .he d.alog is being used (referenced), a Schedule frequency 
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340 by which the dialog is being displayed to a patient in a specific program, 
definition of Reporting requirements 350, and Patient Identification information 
360 and metrics of each individual appliance to which the dialog is assigned; 

The user interface is easy to use due to the simplicity of program structure 
5 in which the user is able to interface with the program and dialog composition 
aspects of the system. Simply using drag and drop content selection procedures 
based on a medical decision creates a process familiar to the user. The user 
decides what aspects of care are relevant for a given program or for an individual 
patient and in most cases simply selects existing content based on that decision. In 
10 all steps of dialog composition, certain steps are taken to make available the dialog 
in a content library. 

FIGURE 4 is a flow chart depicting the steps in creating and storing of 
content data from a dialog, a user's first task is to name the dialog-to-be created as 
depicted in block 400. Next, the user defmes the library section of block 410, in 
15 which the dialog will reside. The user then identifies an aspect of care at block 420 
to which the dialog will primarily refer. Once the naming conventions are assigned 
and the aspect of care is chosen, the user creates dialog programming statements at 
block 430, in a graphical programming environment as embodied in FIGURE 5. 
New dialog content is then stored in an appropriate user library at block 440. 
20 The user who has access to create new content does so using a simple 

dialog composer as embodied in FIGURE 5. FIGURE 5 is a diagram depicting the 
creation components of a dialog Editor Platform. First, a user is presented with a 
palette 500 of programming statements that are represented as graphic symbols 
(icons) that can be dragged from the palette of available statements into a dialog 
25 construction platform 505. In a typical embodiment of the present invention, the 
user drags a siart question icon 5)0 and a three pronged answer icon 520 from an 
icon palelte down to the construction platform 500. The user then activates a 
dialog box for each icon by clicking on it with a mouse and specifying a question 
associaied wiih thai particular icon, for example, a Start Question Dialog 515. 
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Next, in an Answer Dialog 524, the user enters three answer options relative to the 
start question and assigns a raw risk value to each answer 526. The risk values are 
assigned from high to low with a corresponding text answer. "Yes" equals low 
risk and "no" equals high risk and "medium" equals somewhere in the middle of 
5 low and high risk. Follow up questions . icons 530 are dragged onto the 
construction platform along with an associated answer icon 540. An answer dialog 
545 is then prepared. Clicking on the output icon 550, the user activates the output 
dialog box 555. Here the user defines risk state output 558 in detail, further 
depicted with more particularity in FIGURE 5, defining the position of the answer 
10 relative to the axis of the risk cube. At any time during or after the dialog creation 
process, the user can review the dialog created, using a simulation interface to an 
appropriate appliance or in the alternative, the user can review the actual dialog 
content in a text only overview window. Once all the follow up questions, answers 
and output dialogs are formulated and put onto the construction platform 525, the 
15 newly created dialogs are store in a user library 560 from where it can be 
referenced for participation in any user defined care management program or for 
later updating or editing. 

FIGURE 6 is a block diagram illustrating the three dimensional aspects of 
the dynamically determined risk state output scale which in the Dialog Composer, 
20 FIGURE 5, is referenced at block 558. The X-axis 610 scales whether the answer 
to a question dialog sets the risk at a certain risk level on a 9 point risk scale or 
whether the answer moves the patient risk state in a certain direction and by how 
much, thereby creating an accumulated risk profile. Additionally, the answer to a 
dialog is incorporated as a value in a mathematically calculated risk stale that may 
25 incorporate other answers as well, creating a composite, weighted risk state. The 
Y-axis 620 refers to the actual aspect of care in which the risk will be 
incorporated. The Z-axis 630 incorporates the expression of risk 530, i.e, whether 
the risk is assigned to a sign or symptom 632, a behavior 634, or a knowledge 
expression 636. This dynamic model allows for very sophisticated risk profiling 
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including risk trend alerts, composite risk profiling by aspects of care and profiling 
by risk expression. The dynamic risk "foot prints" available at any Hme can serve 
as triggers for automated content selection. 

Once dialogs are named, created and assigned to an aspect of care and the 
5 risk output is assigned to the appropriate dialog, a user of the system can then use 
the Program Composer 30 to create the program that eventually is assigned to a 
patient. 

FIGURE 7 is a flowchart depicting the creation of "programs" using the 
Program Composer User Interface f 'UT*). The UI is a platform for selecting 
10 library resident Dialogs created as depicted in FIGURE 6, for participation in user- 
defined care management programs. In a typical embodiment of the present 
invention, the first step is to name the future program block 700. Next, at block 
710, a user selects the disease libraries from which the program dialogs are 
created. Simultaneously, at block 720, the user checks the Utilities Library to add 
15 dialogs to the program that are not disease specific like generic greetings. This 
gives the user access to the detailed content of both of these libraries organized by 
aspects of care and their respective dialogs. Creating the program is now a simple 
task of adding dialogs to the program list, see block 730, and at block 740 to 
define the delivery of the dialogs as a user can choose specific delivery of the 
20 dialogs on a daily 750, weekly 752, or any other 754 programmed timed basis. 
Additionally, at block 742, a user checks the priority of dialogs to set parameters 
necessary for the correct scheduling of the dialogs in the program. Options are to 
force the scheduler to include the dialog block 744, or to assign dialogs as fillers, 
block 746. The later could be the case, for example, with trivia type dialogs, 
25 entertainment dialogs etc. Also, Ihe user has the opportunity to decide the 
placement of dialogs in daily sessions. Greetings, for example, should be checked 
as "always first." The user can review the complete created program using the 
' View Selection" link, block 760. Using a very simple interface, the user has now 
created a .totally custom made program. At block 770, the program is now 

8 
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available for assignment to any of the user's patients or for later modification by 
the user by adding or deleting dialogs. The present invention embodies the 
assignment by way of a Linker User Interface ("Linker UT) as depicted in 
FIGURE 8. . 

5 FIGURE 8 is a How chart depicting the Linker UJ, which is a platform for 

assigning or "linking" care management programs to patient populations or to 
individual patients. The first step at block 800 is to retrieve patient's name(s) to be 
used on the work platform through a filtering or sorting procedure defined by the 
user. Next, at block 810, the user marks the patient(s) and the care management 
10 program to be assigned. Finally the user creates the 'TJnk" to activate a dialog 
box that allows the user to specify a time frame in which the program will run for 
the selected patient(s), block 820. Should the user wish to link the patient to other 
programs all that is needed is to repeat the process. To process the linking of an 
entire population or part of a population a user selects a)l patients, block 800; and 

15 assigns all of them, block 810, !o a program. 

The last step in the creation of a system program is the creation of a 
Reporter User Interface ("Reporter Ul") which creates patient reports specific to 
patient results that in turn can initiate program actions based on those results. 
F1GURE 9 is a flow chart depicting the Reporter UI and the creation of reports. 
20 The layout of the Reporter Ul is completely consistent with that of the Linker Ul 
depicted in FIGURE 8. First a user retrieves patient names through a filtering 
process, block 902. The user filters, at block 900, names through the programs by 
either risk search, block 904, the aspects of care, block 905, within each program, 
or the risk expression, block 906, as defined as a symptom, behavior or 
25 knowledge, block 908, factor. This is done to allow a user to trend a risk profile, 
block ?io, for the patient in the aspect of care where the patient has scored, for 
example, a high-risk-profile as depicted in FIGURE 6.' A user can configure the 
Reporter UJ to display block 920 the actual answers or results that Jed to the 
exampied high-risk profile. Lastly, at block 930, a patient is assigned to a program 
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based on the risk profile or Aspect of Care, Reports assigned to patients can now 
for example, allow the user to see details for each aspect of care, order a report 
printed or write a note that will be associated with a linked event. 

While this invention has been described in terms of several preferred 
embodiments, there are alterations, permutations, and equivalents that fall within 
the scope of this invention. It is therefore intended that the following appended 
claims be interpreted as including all such alterations, permutations, and 
equivalents as fall within the true spirit and scope of the present in vention. 
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What is claimed is: 

1- A system for coding and updating a patient profile and for 
providing customized health information to an individual, said system comprising: 
a server; 

a remote interface for entering in said server questions to be answered by 
said individual; and 

a remotely programmable apparatus for interacting with said individual 
sa.d remotely programmable apparatus being in communication with said server 
via a communication network; 

wherein said server comprises: 

a questionnaire generator for generating a questionnaire comprising 
1 5 quest.ons for determining at least one of a physical condition of said individual a 
mental condition of said individual, and a behavior of said individual, and for 
transm.t.mg said questionnaire from said server to said remotely programmable 
apparatus; 

a data gatherer connected to said questionnaire generator for receiving 
20 from said remotely programmable apparatus said individual's physical condition 
.nlo a physical condition profile, said individual's mental condition into a mental 
condition profile, said individual's behavior into a behavioral profile for said 
individual according to responses to the questionnaire; 

a script generator connected to said data gatherer for generating a 
.25 customized script program from questions based on said individual's physical, 
mental, and behavioral profiles, and fpr transmitting said customized script 
program to said remotely programmable apparatus; 

a report generator for generating a report comprising said individual's 
Physical, mental, and behavioral profiles and said assigned customized script 
30 program; and 

a database connected to said questionnaire generator, said data gatherer, 
and said scrip, generator for storing said questionnaire, said profiles, and said 
script program; 

and wherein said remotely programmable apparatus comprises: 

11 
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a communication means for receiving said questionnaire and said script 
program from said server and for transmitting said responses to said server; 

a user interface for communicating said questionnaire and said script 
program to said individual and for receiving said responses; 
5 a memory for storing said questionnaire, said script program, and said 

. responses; and 

a processor connected to said communication means, said user interface 
and said memory for executing said questionnaire and said script program to 
communicate said questions to said individual, to ^receive said responses to said 
10 questions, and to transmit said responses to said server. 

2. The system of Claim 1 , wherein after said responses are transmitted 
to said server, additional physical, mental, and behavioral profiles are created and 
an additional script program is created. 

15 

3. The system of Claim 1, wherein said questionnaire generator 
further comprises a registration means for registering a name of said individual, a 
language of said individual, and a current health condition of said individual; and 
said questionnaire generator and said script generator comprise a tailoring means 

20 for tailoring said questionnaire and said script program in dependence upon said 
language and said current health condition of said individual. 

4. The system of Claim 1, wherein said questionnaire generator 
further includes a confirmation means for confirming with said individual said 

25 physical profile, mental profile, and behavioral profile. 

5. The system of Claim 1 , wherein said $cript program comprises: 
a request for clinical data; 

a monitoring question; and 
30 educational information. 

6. The system of Claim 5, wherein said educational information 
comprises, means for accessing an external source of additional educational 
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information and means for transferring said additional educational information 
from said external source to said remotely programmable apparatus. 

7. The system of Claim I, wherein said data relating to said physical 
condition of said individual comprise measurements which are received from a 
monitoring device connected to said remotely programmable apparatus/ 

8. The system of Claim 1, wherein said data relating to said physical 
condition of said individual comprises medical claims received from a managed 
care organization of said individual. 

9. The system of Claim 1, wherein said data related to said physical 
condition of said individual comprises electronic medical records received from a 
health-care provider of said individual. 

15 10. A method for providing customized health information to an 

individual to induce a modification in a health-related behavior of said individual, 
said method comprising: 

exchanging data with a server through a communication network, wherein 
said data includes a questionnaire and a script program executable, by said 
remotely programmable apparatus to communicate questions to said individual, to 
receive responses to said questions, and to transmit said responses to said server; 

storing said questionnaire, said script program, and said responses to said 
questions; 

communicating said questions to said individual andlbr receiving said 
25 responses to said questions; and 

executing said questionnaire and said script program; 
transferring from said server to said remotely programmable apparatus said 
questionnaire containing questions for determining a physical condition, a mental 
condition, and behavior of said individual; 
30 receiving in said server responses to said questions entered by said 

individual from said remotely programmable apparatus; 

generating from said responses a physical condition, a mental condition, 
and a behavior of said individual; 
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translating said physical condition, mental condition, and behavior into 
physical, menial, and behavioral profiles of said individual; 

generating a customized script program for said mdividualbased on said 
physical, mental, and behaviorai profiles; and 

transferring said customized script program to said remotely programmable 
apparatus. 



11. The method . of Claim 10, further comprising creating additional 
physical, menial, and behavioral profiles and an additional script program after 

10 said server receives said responses. 

12. The method of Claim 10, further comprising registering a name of 
said mdmdual, a language of said individual, and said current health condition of 
said individual in said server prior to transferring said questionnaire; and tailoring 

15 said questionnaire and said script program to said individual in dependence upon 
said language and said current health condition of said individual. 

13. The method of Claim 10, wherein said script program comprises: 
a request for clinical data; 
a monitoring question; and 
educational infomialion. 



14. The method of Claim 13, wherein said educational information 
comprises means for accessing an external source of additional educational 

25 information and means for transferring said additional educational information 
from said external source to said remotely programmable apparatus. 

15. The method of Claim 10,. further comprising generating a report 
comprising said individual's physical, menial, and behavioral profiles and said 

30 assigned customized script program: 

16. The method of Claim 10, wherein said data relating to said physical 
condilion -comprises measurements which are received by said sewer from a 
moniloring-device connected to sa.d remolely programmable apparatus. 

14 
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17. The method of Claim 10, wherein said data relating to said physical 
condition of said individual comprises medical claims received from a managed 
care organization of said individual. 

5 

18, The method of Claim 10, wherein said data relating to said physical 
condition of said individual comprises electronic medical records received from a 
health-care provider of said individual. 

10 19 A dinician computer system, the clinician system in 

communicating with one or more patient device, the clinician system comprising: 

a database comprising questions, answer and follow-up act ions; 
a display; 

a processor; and 

a graphical user interface executed by the processor and presented on the 
display comprising: 

a selection component for selecting a question, answer or follow-up action 
from the database; 

an icon generator for generating and displaying an icon associated with the 
20 selected question, answer or follow-up action; 

a linking component for linking displayed icon; and 

a conversion component for converting linked displayed icons into a scrip 

program; 

a sending component for sending ihe script program to a patient device 
25 over a communication network. 



15 



15 



WO OJ/69505 



PCT/USO J/086 W 



APPENDIX A 



i I 



1 1 



16 



WO 01/69505 PCI7US0J/036H 



FIexCube2Q00 
Prototype Requirements 
and Implementation Notes 

July 16, 1999 



1oJ30 



WO 01/69505 

PGT/US01/086J-1 



*»*.W_ Table of contents 

fntroduciion ~ J 

Implementation.. 



Resource Utilization ZZZZZZ'"-' " ~ - ZZ 4 

System Components \ ;. * ** • 3 

Applications L_.„ ~ *" — : ; ZZZZ I 

Appliance.. „^ * * " — - Z ^ 

Windows GUI.....:. ~~ ~ — - Z 6 

Future Additions... ; ~ — r ~>...ZZ 6 

Implemeotation Strategy. " ~ " — ~ 7 

; - - - Z~8 

Mi estoue 2 - Present a Session on the Appliance^ ~ ** -~ 8 

^estonea-Round-TripbetweenServer and Appli^r " - 8 

Milestone 4 - System folly Alpha ..... , W ' • 8 

Strategic Requirements- '. _ *~ g 

Database Highly ScahblZZZZZZl ~~ ~ """" — ™ ' ■ r-ZZZ. 9 

Portable Content and Results . ZZ [ • : .-. 9 

Secure and Reliable : 'ZZZ ' - ~ 9 

Automatic Generation of Adaptive Content ' : ~" ■ - 9 

Multiple Patients per Appliance ™ ' ? - - 9 

Multiple Content Senders 1 Z ~ ' v " ~ 9 

Multi-Lingual Parallel Content ZZZZ : _ ; 0 

Independent Appliance Decisions based on Patient Data* * ~' ' ' _ 9 

Ad Hoc patiem communication .... — ■ 9 

Appealing Graphical UI._ ZZZ ~' r " • 9 

Interface to Patient List Server ~ ~ ... 9 

Reports Summarized by Hiejarcb^Su^iure — 9 

System Components ~ 1 : — irj 

Application Server Scbema/DatabaseZ. ~ ' «IJ 

Requirements ■ **" " : :.. j 1 

Components / Schema Objects...! " 1 1 

Account Entity /Hierarchy Z " • * - - 1 1 

Implementation Notes. '. '* 12 

Seeing '-*-- ~ 13 

Efficient Hierarchy /D^4^^^~" V" : 13 

Cube State Retrieval " ' 1 3 

Content Exchange ' " " 1 3 

DaU Aggregation : * r '~ : * • — ~ 13 

Program Security .... Z ~" ~ 14 

Status Group " — "*•* ~~ „ ; j4 

Features: . " "* : ,...._,v.r 14 

Thoughts . ""■ • ; - 14 

Issues ~ -V ^ 14 

Health Buddy Database (BDB) ZZZ * : " " • ' U 

Appliance Requirements.... ~ *" - 15 . 

Required BDB Appliance Formal ' " - " " — — 15 

ImplementaUon Notes * " 15 

Initial API._... * " * " : - 15 

Questions ** "* * "* ■ 1 6 

Cube Object " ~ ; • ; ; ]6 

Requirements....;.. ....... ** : * : 17 

Implemeotation Notes ZZ ? " r " - I 7 

Issues * 17 

Dialog Object ZZZZ v " "• " : : 17 

18 



2 of 20 



WO 01/69505 . PCT/US0J/086M 

Requirements 

Appliance _ ; _ "" ■ 

Appliance-Summary M ;:;;:;/;n::r.j.::—~..n:. .......I..-. : . * • "* ^ 

Requirements „ „ \ " * 0 

Appliance Appncatioos~-ToDoList Architecture „ 10 

" I? 



Requirements. 



Box Manager Application; . . ~ 

Requirements ; ; -. . . ... 

User Authentication /Login Manager ; _ iZ. ]Q 

Communications Manager! l ' 
Requirements.. 



Connection Manager.. 

• Requirements '., 

Login Manager . 



Requirements 



Requirements ....... 



Session Scheduler ., 



Future, 



....20 
....20 
...20 
...20 
...20 
.20 



Mail Exchange Manager ,...,/. ; " * *"* 

Requirements ... , \ . 20 

Session Manager ....... .... ' , ^..J. ; * 2 q 



„.20 

FlexCube Presenter Application . .1 . . . 2 | 

Requirements „ ........ .......... *** 2 1 

Windows GUI Applications ............. 22 

Dialog Editor . — . _ ** 22 

Requirements ; [ 22 

Requirements „ ; _ _ ~ " 22 

Program Selector _„ _ _ ^ „ / - * ' ^3 

Requirements...... .-. ; _ _ 23 

Program Linker . . . ; .„„ _ " 24 

Requiremenis .... ...... . „ _ ; 2 4 

25 



Requirements ;\_ _ j _ . 2 <j 



.25 



Requirements ; „ ^ _ 2 g 

Administrator..... '. : : _ 2 ^ 

Requirements; ' w _ : 27 

Future Additions ....... .. ... ..... 28 

Enhanced Scripting Language „ . _ 2 g 

Requirements........... _ ....28 

Thin-Client Applications _ _ w 28 

Questions.! . - * . . 2 r; 

Thoughts / issues -. . _ r - 29 

Input..-: ...^ - -1!..!ZIIIZ*I"I29 

Albert Schema Questions , „ „ _ _ ^ 29 

To Purchase ........... „ m ^ 2 q 

System Features / Requirements j „2. '. : J29-. 

Escalations ..... . 29 

Minimal time and effort required to manage content. ; _ : „ 29 

Glossary _ _ ^ \ ^ . u 30 . 



3ol30 

t 



■VVO 01/69505 



PCT/US01/086M 



Executive Summary 

Introduction 

for initial toting will not be scalable* tnHi T fi 7 ) teqmred * n **' Version. Tte database n^T 

.mprove content development ami patient care; ffiX^aJS 8 ' $ "* SyStem "» radically 
given populaiioa F . " e. wiuie reducmg the human resources necessary to manage a 

Implementation 

they are based on completely ffiESTS "^'"alys.s data between the two systems since 
FlexCube- sessions in, 'J&SSS^ T™' " Sh0U ' d be Strai 8 h '^d to conve^T 

to allow larger scale .estin- * "* fUu ' e - An0ther °P»°» » to boild a mini-patient serve- 



^!S^X W S Sl^ii"! 1 " ' 0 i 7 l?ffiM fc «*■ Cube and 

and enhanced scripting language^ &^tT- W,n,e,ni ' e,He,,,,,B »*«TD»«»l«e(BDB) 
as both remote and dati-cefte lL Tn ? ^ ° PC ' 3,e - A sin B ,e schc ™ be leveraj-ed to act 
B^between^^^ 

manager in an organiiL co^ZTf^r^f ' * ^ ^ Fw «^Pk. «eh care . 
and results for aggregate repor^g ** 3PPbC:,l " >D m ' ™* ^rver could track content 

^a^ 

<o snppor, the cube and drategs^Sy mSSS£^ SUb "° aliDeS 
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Resource Utilization 

Erik Jensen (Creator of the HexCube concept)- Will provide overall manaeen,,-,,, - . 

functional and nser-inferaction portions of the system. management, direction m the 

Damel Lindsev r Will provide engineering direction and goidance throughout the nrod.^nn riu 
prototype system. Work with Albert Bodenhamer lo design databases. ^P^^onof the 

AlbertBodeniamer-Wm be response 
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System Components 

• Health Buddy Database (BDB) - A micro database object thai moves cube content, dialogs andraw 
response information to and from the appliance yia XML 

■• XML.Scheroa Objects-For transporting Patient Cubes, Dia!ogs v Box Control Info, etc. 

• Application Server Schema Stores patient data, patient demographics, personalized program/dialog 
content, patient cube-state, and raw response data 

Applications 

Appliance 

• Bo* Manager Application - High level control over appliance functionality, implements to-do list 
° Session Manager - Manages To Do list, launches content applications 

FlexCube Presenter App - Provides sessions by executing dialogs and updating cube state 

• User Login Manager - Enables patient login and authentication 

• Communications Manager - Overall responsibility for non-conversational communications 

• Connection Manager — Brings up physical connection • 
Logm Manager -Responsible for logging into host system 

• Mnil Exchange Manager - Responsible for data exchange between appliance and host 

Windows GUI 

• Administrator Application - Provides system maintenance and data entry features, account setup 
patient entry, etc. . 

• Dialog Editor / Composer - Enables the creation and maintenance of non-personalized dialogs within 
libraries, dialog labeling, and import/export capability to the application server dotabase 

• Program Selector - Selects dialogs from libraries in and out of content specific programs specifics 
labels for scheduling and reporting . ■ . ' 

• • Personalizer - Maintains patient-specific cube metrics, defining risk levels, etc. 
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Session Scheduler - Semi-automatic creation and scheduling of patient speci fic sessions 
- Reporter - Patient results lookup organized into levels from patient- specific program overview to raw 
results from particular session, including graphical body system view. 

Future Additions 

• Enhanced Scripting Language - Enables the appliance to manipulate BDBs, supporting raw data- 
collection arid cube /dialog interaction * 

• Appliance Apps - Script Language implementation of appliance applications. 

• Thin-Client Reporter -Allows system access via the Web 

• Global Patient List Server - This server maintains a list of all patients that HHN has serviced. As 
new patients are added, they will be assigned a Globally Unique ID, which will follow them around 
our service. 
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Implementation Strategy 

Milestone 1 - Build Foundation and Design System 

Initially, construction will begin on foundation objects and code *hile design decisions am h™. fi r » 
for ^ system architecture. Inundation work includes BOB topIemenSEn^nced^clr 
Envuonment, and enhancement leveraging NB V Composer into Dialog Composer Tie final svstem will 

ct^Tn^^ 

• ^Rough-draft GUI design 
• ♦ Project Schedule 

• Scripting Language Selected 

• Archilectural decisions finalized 

• Rough-draft application server schema 

• BDB library code, suitable for integration onto appliance and Windows 

• Enhanced Scripting environment with HAL support 

• Dialog Editor with branching; calculation nodes, decision nodes, etc 

Milestone 2 — Present a Session on the Appliance 

By Milestone 2. the appliance will be capable of dovvnloading a session generatedby the Windows apps 
and present the session to a patient. 5 apps 

• Finalized Schema 

• Finalized GUI design 

• Windows apps scheduling content into sessions 

• Windows apps generating output XML 

• Appliance reading content XML into internal format 

• Presenter application on appliance able to read BDB and present a session 

Milestone 3 - Round-Trip between Server and Appliance 

• Windows apps sending scheduled session content and receiving results over the serial cable 

• Appliance presenting the session and recording results 

• Windows apps uploading results from appliance and displaying raw response and cube data 

Milestone 4 - System fully Alpha. 

B ^Tu m J' ^ WKance will be polished and dependable through the serial link. The Windows apps 
will be jjMy functional and include all essential rationality to make the system work. Wizards will have 
Deen added to support appropriate system functions, especially for content composition 

• Windows apps generating reports and displaying patient status 

• w 'zard fcmctfona^^ 

• Appliance ready to demo 
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Strategic Requirements 
Database Highly Scalable 

.We ultimately need to support 10*s of thousands of users and Millions of appliances. 

Portable Content and Results 

Other appliances and systems should be capable of presenting and processing our content 

Secure and Reliable 

The system must provide controlled access to patient data, system functionality, and maintain secure 
communications 

Automatic Generation of Adaptive Content 

The system should focus content where each individual patient requires the most attention. This needs to 
happen automatically so that we can support very large patient populations with a small group of Care 
Managers. 

Multiple Patients per Appliance 

This will open up the possibility of installing appliances at centralized locations, such as pharmacies. This 
will also enable families to share an appliance within a home. 

Multiple Content Senders 

Each patient using a Health Buddy needs the ability to subscribe to multiple content providers. For ■ 
example, a patient from Kaiser might subscribe to a diabetes program, a weightloss program, and a heaJth 
newsletter from another organization. 

Multi-Lingual Parallel Content 

The system must support the large number of non-English speakers throughout the US. This feature creates 
the potential for a global marketplace. 

Independent Appliance Decisions based on Patient Data 

Immediate Patient Feed-Back 
Ability to Score SF36 on Appliance 

Ad Hoc patient communication 

Care providers need to be able to send personal messages and queries outside of a patient's normal" 
programs. 

Appealing Graphical Ul 

The Graphical User Interface must be pleasant for the care providers who will be using our system Tor 
hours at a time. 

Interface to Patient List Server 

This system needs to communicate with a centralized server that issues Globally Unique Patient Ids! This 
will facilitate knowing that John Smith at Kaiser is the same John Smith at Stanford's Clinical Research 
Program, etc. 
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Reports Summarized by Hierarchy Structure 

This wai.cnairie the system to mesh with future Information Systems. 
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System Components 
Application Server Schema/Database 

The AppiicalioD Server Schema is the heart of the FlexCube system AIM,,, n • , '■ 
datobase. Come* deye.op„*n 

a ^P°^dbe, W ee 0 ,hei„s»^ " 
r ^paue^^ 

Requirements 

• Fast Cube slate removal for an arbitrary date/time stamp enabling report* In L. , 

• Acxoumsareajwaysr^^ TO " * ° Micd 

• Ability to Import and Export content between Application Servers 

• Ability to aggregate data from multiple Application Servers- for eeni^t,™ 

• Support Arbitrary Client Hierarchy ' ^ *r general^ -aggregate DSS-reporting- 

• Support the following Objects 

• Account Enn-ty/ffi^ 

• Group - Allow Cafe Managers to arbitrarily group their patients 

• Paneot Notes *■ 

• Patient ' 

• Patient Demographics 

• Medications 

• Escalations 

• Patient Cube States 

• Program 
. • Dialogs 

• Raw Response Data 

» Program Session Schedules 

Components /Schema Objects 

• System Table -Include Server GUID 
9 Account Enliry /Hierarchy 

' Group 

• Patient 

• Demographics ■ 

• Acci Entity Notes 

• Medications 

• Escalations 
Program 

DiS^ 
Response Data 
Session 
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Sample Application Server Hierarchy 



m- A»l )**• 



Origin* Xtirt 



&QPPA 



OH -Dart* 



D». Jofoto* 



Account Entity / Hierarchy 

al.ow HHN-s real JLlSSESES " ° f ^ ^ 

account within theTyLm. ^ aCC °" nt """^ ^ eDtricS estab,isb ^ roo( * «cb 

be created ari pteed be^en eae^A™ ^E*?? ** ***** '° ^ CT,ries - ™er can 
ten.,^ wWsJ et^ 7k 3 ^.^^'^^"^ actual structure, 
others may ^ly ^[L^Tf ^ D IT 0 "' ^ H6s P i,al - Use ». P^enU, W bile 
an account ^ ^ U °°- ^ Pat,Cn,i Tbe SUD P lest f °"» « to enter all users directly under 

CCeS ' '° SyS,em - Somc ent "«- s >*b " locarioD. may „ CYCn be .Mowed to 
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only establish a reporting framework. Access to various applications and features within the 
^temwUibe set on anentryby entry b 

Programs arc tied to these hierarchy entries. Programs that are tied to a user (Doctor or Care M, , it 
'IS idcrcd r ale - ™«^P^^ 



Implementation Notes 

Scaling - 

Several tacu'es have been employed to support ten's of thousands of users and millions of appliances. An 
account must fit on a singfe Application Server. However, utilizing SuperNova. an arbSSof 
Appbcabon Servers may be established to spread the load. ^ *umoer.oi 

By configuring the SuperNova distribution of newxontent and results to send copicsto an asEreeation • 
server. Aggregation reports, combining data from moltiple accounts, can be generated in parallel bv 
combining data from many servers while the individual Application Servers continue to run supportine 
users and appliances. , ^u^uiujig 

Normally, an account database can not be split across multiple servers. However the possibility of 
spreading the load is possible by utilizing replication technology. Oracle is one of many database systems 
with automatic replication services. This permits multiple Care Managers and Doctor* within an 
organization to each operate on a local database and stay in sync with the centralized organization server 
Agam. this provides a way to scale servers and ultimately grow the system to very large sizes. This is * 
probably not low hanging fruit. The amount of effort necessary to implement this setup is not know at this 
h me. However, this problem has already been sol ved in other systems. 

The depth of the content hierarchy has been kept as shallow as possible to remove the likelihood of 
recursive.queries, Wherever possible, the schemahas been designed so that all related elements can be 
grabbed id one query and assembled or sorted within the client . 

Efficient Hierarchy / Database Interaction 

Rather than implement recursive SQL queries to grab and build hierarchies. Use the account index to grab 
all entity vvuh one query. The HHN hierarchy can also be retrieved using the same method. If necessary 
bom can be retrieved m a single query by combining (acctS eq searchacctf*) or (acctf eq 'CORPHHIT). " 

Cube State Retrieval 

Retrieving a Patient's Cube State for a given point in time will occur very often during system processing 
hc mosl cf " cl «* means we've found of retrieving a cube uses the foUowing mechani sm: 

Cube Metrics or Values are stored in a table indexed by Cube ID, AoC, Expression. DateEffeclive, 
An addiuonal field is added to this table called Replaced Date. 

A Database trigger is responsible for updating the Replaced Date field whenever a new record is 
inserted. This places the update in the most efficient place, saving wire-time, SQL parsing, etc 
This enables a single query to grab the entire cube for a give* patient at a given time as well as the 
current state by using the following queries: 

select * from metric where paient_id=our_patient and 
create_date<search_date and (ianull <replace_date j or 
replace__date<search_date| ; 

Content Exchange 

App Server r s must be globally unique 
Account's 

Globally Unique Object ID's 

Combining Account*? - CM ID. etc in BDBs allowing diff Recrmms in different schemas 



1. 

2. 
3. 

4. 
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Data Aggregation 
Patient GUIDs 

UsingDatabaseRepKcation to spre*! load within-an or^tio^ 
Program Security 

Status Group 
Features: 

• Current Status - Is this an active patient 

menevar a status change event occurs, the following database tf^j. 

• The Current Status is copied into the Previous Status c[I >oo«ed. 

• Z^ eCurfen,Sta »"S" changed to the new status code 

• The Transaction date is updated 

• A ne«, System Transaction Sis assigned and filled in 

• TheSy slcm I> a ,emmebputintotheDateEffectivefieId 
The Database record is updated in the database 



Thoughts 

' ^SBSSS±5i±^ w^s 

' S^St*" ^ ,3b,e *** ««W off One account entity table, si^g our overal, 

• Group 

• Dialog Editor /Composer 

Issues 



Issue 




How to move Content & R csuhs . etc ^ belwecn 
.systems with different RFPWIjm UnJcs 
Program Sharing ' " ~ 


Solution 

^siaousb Ulobally Unique Ids for each object that 
must be moved. 


v-' 
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Healih Buddy Database (BDB) 

control information to interchangeably move between -ADolication W a v v - KU,lS ' ^ box 

Previously, survey content had to be written into script language code and comoiled Rnn. 
code overhead, rerfucbgcon^^ 

even by. systems that don't support ou* VM. A script application can open a comenl al^f '* 
^joas,nv a ry^wa ys , dependingo . npatient req Lm e „ tSi For example pa ZS w.W^"^ 
might be presented content in a larger font. Aam P le > P a ^nts with poor eyesight 

Appliance Requirements 

• Standard XML with BDB DTD 

• Support Multiple Tables - Simple RDBMS style 

• Date/Time stamps encoded using 32 bir Iotegcrs in Unix format 8 . 

• Support Auto-Increinent Integer Type 

• Self-contained for transmission between systems 

• Computable for efficient transmission between systems 

• Must utilize memory efficiently 

• Appliance code must be small 

• C& Java must be able to work with same format 
Fast storage and retrieval of field values 

• Basic Schema info - Table and Field names - embedded in data 

• BDB and Content Format versions • 

• Ability to upgrade library code, enabling shared content in a multi-threaded environment 
Consider exphel One-To-Many record linking mechanism 

• Arbitrary Indexing for efficient reporting (Temp &Penn) 

Required BDB Appliance Formats 

9 Dialog 
•• Patient Info 

• . Patient Program Cube 

• Session Schedule ' 

• Raw Dialog Session Results 

• Box Control 

• Error Log 

implementation Notes 
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Initial API 

This is a current list of API factions/methods for the C irapfementation. Note; This design has not been 

Init_BDB, Creat6J3DB, Destroy_bdb . 
open_bdb, closejbdb, debug_princjt>db 

create_index, delete_index. gec_index_count, select_index 

add_field, get^field^counc, get_£ ield^type, get_f ield_name 

get_record_count, new_recoro\ modify_j:ecord, cojnmit_record '■• 
abort_record * 

first_record, last__fecord, nexc_record, prev_record 
get_numeric__data, se terminer ic_data 

get_string_data_length, get_string_data, get_substring_data, 
get_string^data_mallQc, puc_string_data, put_substring_data' 

f ind_record_numeric, f ind_record_string 

Questions 

• Should we have a glohal DTD and separate DTDs for each object? 
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Cube Object 

Cube Objects are responsible for maintaining patient state throughout the life of a orofrram M>t * 
stored wtthtn thecubeand organized by Aspect of Care, Expression. andialS^o^ Lt£JZ 
Aspects of care foradiabe.es program ^ be Foot Care. Eye ^ Blood a u ™ e M~ 

^ ^r° m ihclude Behavior. Sigo^A Symptoms, and Knowledge. SS e^Li 

System .and Pro-am Vanables. Refined Output Data, ami Meter Readings. OibeobjecuWest 
U.emseJves in different ways throughout Ore system. They are kept in paTtof the aSoT™ 
database, nave, toa^ 

appbance. Internal formate for Cube objects are based on a relational database^. 

Requirements 

• Stores metrics by Aspect ofCare and expression 

... .SUntard ride level metrics with value* TJnknovvn. (-1-3)' Law Risk, (4-6) Medium ttisk, and (7-9) High 

' Wi,h aSCSsion/dial °f "**«?«» we can tracebaekto theinfo that gencratedthe » 

• DataTypes 

• Raw Response Data linked to metrics 
Refined Data &om Output Nodes 

• Meter readings 

• ImpJementauon format must be effident for common reporting requires 

Implementation Notes 
Issues 
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Dialog Object 

Dialog objects are similar to sub-surveys that interact with patients take meter mrtL* i > 
Response BDBs and Cube BDBs. A sugary version of S^^^^ 

apphance. allowrng access ,o cube and response data & 0 m within dialog Tb] S 3S t 
for dialogs to share and pass data. ' ,ms racnanism ts the only way 

Dialog objects are composed of Interaction Evaluation, and Mapping sections The inir,,,- h - • 

- Interacts with patients and provides output to update cube state 
Requirements 

• Dialog nodes (Puzzle Pieces) 

• ^i 7 ^ ^T C) * raCth6dS: Lon *> Choice. Prompt 

OueS ^^^^^^ Follovi P 

Question. Only the Start Question is anchored on the work area. 

• Prompt -Stops and provides text info for the patient 

• Ou* U t : Writesou^ a metric calculation section and a - 
. destination map into the patient's cube *«uon ana a 

• Decision- Allows branching based on expressions 

• C^culaUon - CaJculates a value using raw response, cube, and mafhematjcaJ expressions 

• Goto - Jumps to a label piece 

• Label -Provides a target address for goto's 

• Stop -Halts execution of a given dialog 

Meter - Stops execution and takes a meter read ine 
• Properties . 

Name - Each dialog is named and is referred by name in various parts of the system 
° "taiy-Etch dialog belongs to a globallibrary 
° Tags -Tags indicate special properties 

«> Default Scheduling frequency 

• Default Reporting status 

• Last date/rime executed 

► Localization versions within Dialog Object 
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Appliance 

Appliance Summary 

The appliance requires additional functionality in order to support the FiexCube archirrrh^ a ^ tw - 

appliance and multiple programs or content sources per user. Content, Results EC—'.t 

User and Appliance information will all be.transpofted as BDB XML E - Comme '« Transactions, 

Requirements 

• To Do list architecture 

- a XML / BDB content, results, c-epmmerce. user and appliance mformation 

• New system applications 

Appliance Applications - To Do List Architecture 

Initially, appliance code will be written in CVOh, Later, an enhanced scripting faoguage/VM will enable - 
lv SSSTw! • ^ nen ^ 5CripUDe ,anEU3BC - *" »il*'wifl be rc^omibk fornTnarP L 
p^c^ 

Requirements 

• Box Manager Application 

Connection Application - Brings up the physical communications link 

• Login Application -Logs in and establishes a secure connection 

• Mail Exchange Application 
Session Application ' 

• < Presenter Application 

Box Manager Application 

ceme^^ ^ 0 " e ° f tW ° CVCntS l ° ^ Whe " it>s * "I! intothe data 

Wnev J a B ^ f ^ aaager «■»* rhc Communications Manager and exchanges content, results, etc. . 
Whenever a button ,s pushed on tbe appliance, it calls the Login application to initiate sessions and allow 

Requirements - 1 

• Handles call-in schedule (Box hardwired with call-back failsafe) 

• Calls CommunicatioDS Manager 

• Calls User Login Manager 

• .Calls Session Script upon user authentication 

o Schedules Results BDB for delivery lo application server" " 

User Authentication/ Login Manager 

• User BDB enables/disables user login requirement and style 

• Styles 7 

• Select User from List 

• Authenticate via Luggage Lock (Clapp^s method) 

• Authenticate via Smart Card 

• Authenticate via PIN 
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Communications Manager 



Requirements 

. • Calls Connection Manager 

• Calls Login Manager 

• Calls Mail Exchange Manager 

• Returns success/failure 

Connection Manager 

SSrt" A J*! ic f on be responsible for dialing into our service provider (ISP orEDS} and 
establish** the physical communications link. BDBs will provide a prioritized ES3H ? 
nu*ben : A fallback 800 number will dial.beck to HHN wLever fcSSS^ 

Requirements 7 

• Brings up the physical communications link 

• 800 Number for Fallback 

• Prioritized list of local numbers 

Login Manager 

Requirements 

• Logs into host system 

• Authenticates box 

• Establishes secure connection 

• Navigates prior lo data exchange 

Mail Exchange Manager 
Requirements 

• Retrieves new content and message BDBs — - 

• Uploads new results and message BDBs 

• Uses SMTP &POP3 protocols 

• Will likely use non-standard ports to promote security 

Session Manager 
Requirements 

• Calls FlexCubc Presenter Application to execute content BDBs 

• Prioritized with Round-Robin resolution. 

• Do not present until time/date property 

• Expire after time/date property 

• Required Rag (This must he run before any lower priority content BDBs can execute) 
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FlexCube Presenter Application 

The Presenter Application is responsible for presenting FlexCube contenHo the patients. 

Requirements 

• Presents content packaged in BDBs to patients 

• Writes raw question responses and evaluations to a BDB 

• Updates Box cube state j 

• Supports standard input methods * ! ! 

' ■ ■ I 
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Windows GUI Applications 




Dialog Editor 

The Dialog Editor application is the primary tool for content development 

Requirements 
Requirements 

• Experience Levels 

• Beginner View -Holds author's hands, but doesn't allow M use of system 

• Expert View- Enables all features, expects author to fully understand system 

• Editor Views 

• Graphical Editing view 

• Hierarchy view 

• List view 

Segregate Dialog Pool into libraries 

• Select Default Dialog Properties 

Name - Each dialog is named and is referred by name in various parts of the system 

• Library - Each dialog belongs to a global library 

• Tags -Tags indicate special properties 

• Default Scheduling frequency 

• Default Reporting status 
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Program Selector 




Requirements 

• View/Select available dialogs by 

• Library . . 

• Body System Tag . 

• . Name 

• Set Program Properties 

• Start and End Dales 

• Inclusion and Exclusion weekdays, dates, and date ranges 
° Default Reporting Status . 
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Program Linker 




* xvianagcrs 10 set program parameters on a patient by paiient basis. 

Requirements 

, • UnkAJnYruk an arbitrary fist of patients into or out of an arbitrary list of pro-ams 

• Set panent specific program properties <°i programs 

• Start /Stop dates 

• Include/ Exclude specific weekdays 

• Include / Exclude specific dates and dale ranges 

• Select and Approve Patient Risk Levels 

• Select/Deselect patients using standard Windows GUI 

a All - " 

• Range 

• Individual Select/Deselect 

• Sort List by 

• Name 

• Date of Birth 

• RiskProGle 
. •• Custom 
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Session Scheduler 

Session scheduler is the application responsible for scheduling and managing content presentations on .h, 
appliance. H can run as either an automatic engine or as an interactive utility. It is ako S for 
reviewing and editing session data. . 

Initially Session Scheduler will run in semi-automatic mode. Care Managers will be able to select a 
patient /program combination and then view the scheduled sessions. Filter control will be provided 

Requirements 

• Manual and Semi- Automatic Session generation ' 

• ^Ability to view and edit listed sessions 

• Session status indication - Generated, Deployed, and Completed 

• Session Boundries 

• Dialogs prioritized within a session 

• Limit on total dialogs in a session . 

• Dialogs selected based on individual cube slate 

• Dialogs selected based on program frequency 

» Round-Robin Dialog selection for equivalent dialogs 

• Greeting dialogs with highest priority 

• Exit dialogs with lowest priority 

• Must Execute Rag-This dialog must Mecute wimput allowing panent choice before lower 
priority sessions are presented as to-do items 

• Inclusion /Exclusion periods for patients -blackout a vacation period 
Intelligent Session Deployment 

• Initially, Care Managers will be required to approve sessions ;, 

Future 

• Support for Population Session creation and scheduling 

• Fully Automatic Session generation 
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Reporter 



wmmmm 




Reporter is the primary application for reviewing patient results and status as well as paper reports The 
Sonr;o^r" Cn * 8 ^ CUeDL La,Cr ' ^ ° f ReP ° ner WUI ^ d » ph ™ cA a -SSe^ 

Requirements 

• High Level Patient View 

• Clickable Human Body ia patient detail view 

• Patient Summary Report 

• Population Summary Report 

• Raw dialog results viewer 

• Report generation summarked by hierarchy 
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Administrator 

Adrnimstrator is the application that manages overall system operation and configuration. 
Requirements 

• Account Entry/ Maintenance /Status Changes 

• Patient Entry/ Maintenance /Status Changes 

• Copy Programs between Account Entities 

- System Coafig, Patient Entry, Account Entry 
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Future Additions 
Enhanced Scripting Language . 

fc^S.h.cturesmafeirpossibl^ 

with other systems using the modem or serial port. P * '° et>rn ™at 0 

Requirements 

• Structures passed by value into functions 

• t£T "* SUPPOrt Pf5mi,iVe *»* 32Wt & Variable length binary 

• Full HAL functionality . - 1 

• Serial & Modem communications support 

• Date & Time types 

Thin-Client Applications 

Thin Client Features 

V Universal access via HTML browser* the system over .be internet 

• ij.obal Access to data 

• Eliminates deployment issues 
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Questions 

• In ihe rirsi prototypc should we aim lo create sessions on a program basis, patient basis or both? 
(Patient Basis First) . ■ 

• Should we build a schema capable of multiple accounts? (YES) 

• Can we realty merge raw <iata into ihe cube? (Probably, but it would be more efficient to store 
seperatly): 

• Should a patient have a cube for each program? 

Thoughts / Issues 

• We need to support shared puzzle pieces 

• rMaybe have a Global AoC for things like HMO procedure approval screens: Your responses indicate 
physician attenUon is required, please call Dr.Smith if you do not receive a call from your doctor bv 
tomorrow... , J - 

• Need easy way to leverage into thin-client 

• CanweaskMitchlomcludeusih^^ 

• Wizards - 

• GUI hand-holding methods -Help, etc... 

• Sharing of Dialogs between accounts 

• Moving data between data centers 

• Dialog Interaction Precaution Tags 

• Dialogs that refer to outside AoCs 

• Development Hardware 
» Investigate DB2 

Input 

■ 8/23/99 - All new patients get tossed into a special group "New Patients(5)" to make it easier for CMs 
to put into programs. Avoid one big pile of patients where you can't tell who is new, etc... 

Albert Schema Questions 

• Many to many on Patient / Account Entity .... 

• How do we move data between DBs? Vm sure this problem has been solved before in various ways. 
But, we need to figure out how. One thing I think we can do is integrate account fl into the XML tbat 
we send. Even if it's not part of a given table. This may assist in reassembling the relationships at the 
destination. Another note: Accounts roust be globally unique between all data centers. 

To Purchase _ 

• DBATool(s) 

• VMWarc 

• Order Oracle? (v 8.03/8.04 issues- CB4 Driver requires a version higher than we have.. .) 

System Features / Requirements 

• Hidden AoCs within Cube 

• Escalations 

Escalations 

Minimal time and effort required to manage content 
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Glossary 

Application Server - Computer system including appliance communications and thih-client web front-end 
and a database of content, patients, account entities, scheduling, and results. 

Aspect of Care (AoQ -'A topic within the Cube Object. Aspects of care for a diabetes program might be 
Foot Care, Eye Care, Blood Glucose Management, and One-Touch BG Meter. 

BDB - A micro database object that moves cube content, diaJogs, and raw response information to and 
from the appliance. BDBs travel in XML form. 
Database Schema - Stores dialog and program content 

Cube Object - Stores patient state, includes Raw Response Data, Refined Patient Data, and Meter Data, 

Dialog Editor / Composer - An application for creating and maintaining non-personalized dialogs within 

the Dialog Pool in an Application Server. " - 

Dialog Node - An executable object within a dialog. These correspond to the puzzle pieces in graphical 

view. Examples include: Question, Output, Goto... - 

Dialog Object - Interacts with patients and provides output to update cube state 

Dialog Pool - The section of an Application Server that contains content dialog objects! ; 

Expression - A subtopic within the Cube Object. Expressions are typically Signs & Symptoms Behavior 

and Knowledge. ' ' 

Globally Unique ID - Unique identifiers for patieots and other database objects, enabling data portability 
and aggregation. 

Library -The dialog pool is partitioned into libraries. An attribute of a dialog. Typical libraries might be 
Diabetes, CHF, or Utilities 

Localization -^The ability of a system to support non-English languages 

Metric - A measurement, most meuics are risk levels or meter readings. The third a* is of tbe cube 
Personalizer - Mainlains patient-specific cube metrics, defining risk levels, etc. 

Program Selector - Selects dialogs from libraries in and out of content specific.prograros, specifies labels 
for scheduling and reporting 

Puzzle Pieces - A reference to the graphical objects in the dialog editor. Puzzle pieces include: Start 
Question, Followup Question, Prompt, Output, Decision, Calculation, Goto, Label, Stop, and.Metcr. 
Reporter - Patient results lookup organized into levels from patient-specific program overview to raw 
results from particular session, including graphical body system view. 

Schema - A database design, specifying the data stored and relationships between different parts of the 
database 

Script - Byte code used to implement appliance applications, and evaluate expressions within a dialog • 

Session Application Script - This is a compiled byte-code program that presents content to a patient. In 
FlexCube. this application will present diaJogs and manage cube-state within the appliance as well as 
manage synchronization between the appliance and data center. 

Session Scheduler - Seroi-automaric creation and scheduling of patient specific sessions 

SuperNova - An archive and distribution infrastructure for HHN system components. FlexCube is the 

data. SuperNova is the highway. — 

Tag - An attribute associated with a given dialog / patient or dialog / program. A typical tag might be 

presentation frequency. 

XML - A text based format for encapsulating and transporting data between systems. The generic format 
used for HHN's data is called a Buddy Database (BDB). Acronym for Extensible Markup Language. 



30 ol 30 



WO 01/69505 PCT/US01/086J4 

APPENDIX B 



1/2.9 



WO 01/69505 PCT/IIS01/086N 

Consumer Applications: Long Distance Care 
High-Level Requirements and Design 



DRAFT 



© HHN Software Products 
2505 Meridian Parkway Suite 175 
Research Triangle Park NC 27713 



in*) 



WO 01/69505 

Table of Contents 



rCT/US01/086J4 



1 Vision .1... 



1 . 1 vision for Long Distance Care * ZZZ Z ZZZZZ* ~ I 

1.2 Documentation _ . -■—;•»-• » 3 



2 Scope., 



3 



2.1 The Market ; _ ZZZZZ. • ~ " > 

2.2 Benefits to customers r . . " ""**"*""" "** ~ 4 

2.3 Benefits to HHN ZZZZZ " ' ***** "f 

3 User Scenarios „ 



5 



3.1 , s Sign up/enrollment......: .......... 6 

3.2 Program Delivery ' „...Z..ZZZZZZZZ : ~ :*" : ^ 

4 High-Level Requirements. g Z ^ '•••**' 

4.1 Workflow diagram ZZZZ Z 8 

4 2 Health Hero Services Introduction/Splash PagVZ!ZZZZZZZZ!ZZ. 9 

— — .....^ 9 



4.3 Member Sign Up 

4.4 Credit Card Billing Z...... ............ 10 

4.5 Personalize Program - Wizard for Content Selection and Sc^ "~~^to 

4.6 Personalize Reporting and Alerting Wizard _..„ ; „ * * • * 

4.7 Viewing Status and Reports... ..... * "*"' 

,4.8 Help.— „ t : . ; ZZZZZ ....... 1^ 

4.9 Customer Service .'. ZZZZZZZZZ ~" 1? 

4.10 Long Distance Care Program Content -.'ZZZZZZZZZZZ.ZZ I 13 

5 High-Level Design;. 

5.1 User Interface.. 



15 

15 



5.2 Server-side changes: Database and Middleware..: • ""*"'"" 

5.3 Application Content ; ******* Jg 

5.4 . Survey definition and scheduling Z.Z.ZZZ" ~ 20 

5.5 Reporting ******** """" 

5.5. 1 Reporting Architecture ZZZZZZZ 

5.6 E-Commerce and Fulfillment -ZZZZZZZZZZZZZL " 

5.7 Overall Design Issues ZZZZ 

6 Going Forward 



..21 
.21 
.24 
.25 

26 



6.1. Key Business Analysis Considerations 26 

6.2 Software LUecycle Development 9fi 

6.3 Next Steps ZlZZZIZiZZZZZI ' 27 



J/2!) 



W °<»/«>S05 PCT/US01/08614 

1 Vision 

mu M /!S",u 0 ' 8,0 Consumer aPPfca'tons effort is to provkfe applications outsido the corn 
HHN/OLS that extend the definition of tho care manager and grow the HHN bSss^ntoT 

rrrL ated areas - These ^ eas are in hea,,h car ° »^ is 

ZsT? by ^ nSUmefS and n0 ' by 3 h0S P i,a ' w HM0 - AppHcations ™tfy ur.de 
consideration involve partnerships with: y unDer 

• caregiver.com -Long Distance Care 

• Stadllanders^ Care Management of Stadtlanders (medication) customers 
Weight Watchers ^ Management of people in Weight Watchers programs 

1.1 Vision for Long Distance Care . 

- The largest group of care managers In this country are family members taking care of aqlnq 

Ss^lnv'Tm ^ #In9 hM ,radib '° na " y a rote °' ^ their 40's 

! k l , y °' meSe WOme " are noW teb y boomers In the workforce. Also, the mobility 
HiJSttr 9enera,i ° n , haS reSU " ed in man * chHdren > M n g (a , away from ^ J 
parents and other agmg fam.ly members as well. These two trends have helped create an 

Zme7clildre r n teChn0,0^y " €nab,et, ' Tem ° ,e ™° mana 9 emenl °» olives by baby 

1.2 Documentation 

wi^rW™' inC ' UdeS ma,e " a,S ' r0m ,h ° '°"° Win? documenls hav * been produced 

HHNLDCPreliminaryHLRD.doc 
Informal Caregiver Requirements.doc 
lnformalCaregrverRequirements.doc 
eg pricing.xls 

Term Sheet for Careguide.doc 
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2 Scope 

The scope of this" project Is an application buiR around long distance care. The Health Hero 
Network Long Distance Care Service (HHN/LDC) is envisaged as a . value-added sen/ice to the 
HHN/OLS that enables care providers such as family members to check on relatives m . assisted 
living facilities. The relatives would each have a Health Buddy, and the HHN customers would 
access information via a thin web client. 

HHN/LDC would tie into the HHIM/OL'S to communicate with the people in assisted living facilities 
who would answer daily dialogs by using the Health Buddy. The customer would create 
personalized content for the family member, be informed of certain alert situations, and receive 
reports on the family member's status. 

The HHN/LDC application is in the concept stage and is currently being discussed with 
Careguide.com. This document represents HHN Software Products' preliminary understanding of 
the application based on input from Steve Brown, HHN marketing, and HHN clinical and provides 
a summary of. high-level requirements and a high-level design for the HHN/LDC application. 

2.1 The Market 

10 million seniors live alone, and 2 million seniors live in assisted living facilities. The 
numbers are growing rapidly because of the aging population. While this drives the care 
management and assisted living businesses, it is also creating huge unmet needs for family 
members. 

HHN has test marketed the concept ol. an internet based service that would allow family 
members to monitor parents with a Health Buddy, combining personal messages with canned ' 
senior wellness dialogues and web-based reports for the family member. The initial 
discussions included about a dozen working women who were in their 40s and 50s, wore 
computer users, and were worried about aging parents. Every one expressed an interest in 
paying out of pocket lor such a service "in a heartbeat." HHN has also Introduced the idea to 
three major employers accounting for more than 75,000 employees. Two of these employers 
expressed an interest in offering such a service through their Employee Assistance 
Programs. The price we discussed was $500 lor a one-year subscription. 

More formal market analysis may be possible with Careguide.com as they have 1.3 million 
page views per month from an audience primarily composed of adult children of aging 
parents resulting in 1 7,000 referrals to assisted living providers. 

2.2 Benefits to customers 

The service can benefit the family member, in assisted Irving: 

• Stay home longer rather than going to assisted living 

• Feel more secure, thai someone cares 

• Stay in contact with family member 
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The service can benefit the caregiver: 

• Patient slays home longer saving the cost of an assisted living facility 

• Provides quality assurance of services for patients already in an assisted Mng facility 

• Reduced stress, improved quality of life for the patient and the care giver 

2.3 Benefits to HHN 

• Huge market opportunity potentially in the hundreds of thousands. .' ... 

• Higher price possible 

- ? Consumer private-pay over the.web means less contracting issues 

• More control over network for future services such as e-commerce 

• Additional market exposure for the Health Buddy concept . 

mS^^TVT^ C ° nSUmer ™ rke 'P |ace ™»V °*Pand the awareness of the 

EST ****** US6rS ° f ° ,ner HHN ServiC6S - For exam P'^ P«pte purchasing Z 

HHN/LDC seryice mfght also be diabetics or have other family members whS Sella 
There are also many upsetting opportunities e.g. HHWLDC users might be interested in 
hear.ng about hghlweight, warm robes and blankets that can be shipped to a loved ono. 
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3 User Scenarios 
3.1 Signup/enrollment 

Kate is a 40-year-old businesswoman and mother of three who lives in San Francisco Her 

1°™, t 85 yea ?.° ,d ^ ^ )USt m ° Ved ' ml ° 3 " assfe,ed ,ivi "9 aa she can no 

tonger take care of her homo by herself. Mrs. No vitsky takes several mediations onTdaX 
bas.s. Is occasionally forgetful, arid generally feels somewhat isolated and lonely. 

Kate has used Careguide.com to lind and select her mother's facilily and remembers seeina 
. = e,h,ng about a Health Hero service, she goes back to find out more abouUh S * 

EXES? p,ion seein9 how Hea,,h Buddy works she * «£5!3 

Kate completes the registration questionnaire providing her contact Information as well as 
demographic .nformalion about her mother. She closely reviews the Health Hero services 
agreement and acknowledges her acceptance ol the agreement. She then proceeds to enter 
her credit card .nformatlon to finalize her request for enrolling her mother in the Health Hero 
proQrsm. 

Kate is now on the Health Hero program home page and sees that she can personalize the 
program to meet her mother's needs. She quickly moves through the step by step 
personalization wizard and enrolls her mother in a medication compliance anS wefes 
program. As part e! the medication program setup, she is prompted for Information about her 
mover's medicatrons. Kale is asked if she would Oke to receive a special alert via fax e- 
mall; or pager il her mother's responses indicate that she is not taking her medications or is in 
need of a refill. Kale has no idea how critical this medication is so she clicks on a link that 
takes her to a delated description ol the medication. There she learns that this medication Is 
very important, so returns to the program set up and selects to receive an alert via e-maiL 

She then requests a birthday message for her mom's birthday on Feb S* and a special 
tn.nk.ng ol you" message lor the anniversary ol her father's death. Finally, she enters a 
personal greeting message to be delivered to her mother as part ol the first set ol dialogues. 

Kale decides to accept the default set ol reports and has now completed_enrolling her mother 
m the Health Hero program. She calls her mother to tell her the good news. 

Within moments of completing her enrollment, an e-mail is sent to Kate to welcome her to tho 
program and confirm her mother's enrollment. A Health Buddy transaction is also generated 
to FedEx. 

As FedEx ships the Health Buddy, another e-mail is sent to Kate to let her know that the 
Health Buddy is being delivered to her mother. 
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J-2 Program Delivery 

Mrs. Novilsky has no problem following the. Health Buddy's setup InslmrHnn. , • 

have the prescription delivered.. Pharmacy and arranges to 

At time goes by, Kate has established a routine of togging into the Health u - 

enrolls her mother in a nutrition program, specifies her k^i, vSoJ l 7 
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This section contains high-level requirements received from marketing. These requirements 
currently comprise leatures.of the envisaged service. ^requirements 

4.1 Workflow diagram 



Heallh Hero Semlcos - Informal Caregiver 
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4.2 Health Hero Services Introuuetion/Splash Page 

This web page will contain an introduction to the Health Hero Service and a demonstration of 
a Health Buddy communication. The goal is to get caregivers to sign up for the service. 
Specific features are: 

• Prompt for user login/password 

• Prompt for New User sign-up 

• Forgotten password assistance 

• Links to Individual program descriptions 

• • Links to program enrollment checklists (information needed to complete enrollment 
for individual programs) 

4.3 Member Sign Up 

This section will allow the caregiver/purchaser to sign up and activate the HHN/LDC service. 
Specific features are: 

Member Registration 

• Caregiver/purchaser information demographic, contact, login and password setup 

• Health Buddy user information - demographic, contact 

• User can register but not activate/request health buddy 

• Sign up for a Health Buddy e-mail newsletter (generated and distributed by Health 
Hero) 

• Send follow-up confirmation e-mail for new registrants 

• Send notification letter to patient 

Activation/deactivatlon/upgrades/bundled medical devices 
■» Allows caregiver to turn on service 
o Allows caregiver to cancel service 

• Allows caregiver to purchase upgrade services (i.e. BuddyLink, etc) - future 
requirement 

Billing information 

• Credit card information 

Health Buddy Information 

• User entered information - user specific set up information 

• Additional optional patient information - medications, diagnosis, physician etc. 

• Health Hero maintained information (or Interface from FedEx) - Health Buddy serial 
number, ship date (In the future this may be other device information) 



JO/29 



WO Oj/69505 PCT/USOI/08614 

• Interface to FedEx for Wealth Buddy. Fulfillment 

• Notification of shipment e-mail to caregiver from FedEx 

User agreement 

• Legal agreement/disclaimer 

• Caregiver/purchaser acceptance of agreement 

• Patient agreement will be achieved through a dialogue on Health Buddy 

%4 Credit Card Billing 

This component handles the financial transaction between HHN and the purchaser of the 
service. Specific features are: 

Verify credit card 

• Interface to service for automatic credit card verification/validation 

Credit card billing transaction 

• Link to e-commerce server 

4.5 Personalize Program - Wizard for Content Selection and 
Scheduling 

This component provides a step-by-step user interface that walks the caregiver/purchaser 
through the process of setting up and changing programs and dialogues for a Health Buddy 
user. Specific features are: 

Select and schedule program and dialogues from available library 

• Select from a list of programs and dialogues defined by Health Hero staff using 
existing Composer functionality. Examples of preloaded content are: 

® Nutritional status (e.g. weight, appetite) - 

• Medication compliance 

• Regular (e.g. monthly) assessment tools 

• Enter program-specific Health Buddy user information 

• Link to resources (ie Drug information, 'health handbook* etc) 

Schedule and create personal messages 

• Short message from informal caregiver to patient 

• Appended to scheduled dialogue 
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• Message scheduled for a specific calendar day or a day of week (i.e. one time only or 
repeating) or lo bo delivered in the next communication 

Schedule and create sponsor messages/dialogues 

• Sponsor may be Caregulde.com, Weight Watchers, or other third party 

• Caregiver option (on behalf of patient) to receive or not receive sponsor messages 

• Dialogues created by Health Hero \ismg existing composer functionality 

• Dialogues or messages assigned and scheduled by Health Hero 

• Dialogues or messages appended to consumer-scheduled dialogues/messages 
Specify variables 

• Enter patient specific values for default variables previously defined In Composer bv 
Health Hero staff ■ 



4.6 Personalize Reporting and Alerting Wizard 

This component provides a step-by-slep user interface that walks the caregrver/purchaser 
through the process of setting up and choosing reports and alerte. Specific features are: 

Specify alerts 

• Select alerts from predefined list. Examples might include: 

• Non-response for specifiable (e.g. 3) number of days 

• Significant (specifiable e.g. 5 lbs) change In weight 

• Request from family member for a phone call 

• Medication non-compliance (specifiable e.g. more than 3 missed doses per 
week) 

• Specify when and how to receive alerts 

° Displayed on Health Hero Services Home Page (within Careguide.com) 

• E-mail 

Specify reports 

• Select from predefined list of reports. Examples might include: 

• Nutritional status and weight tracking report 

• Medication compliance report 

• Reports from assessment tools 

• Option to preview a sample of report 

• Specify report recipients 

• Specify report delivery mode - fax, e-mail, display on-line 
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• Specify report frequency - dairy, weekly, monthly, quarterly 

4.7 Viewing Status and Reports 

The careglver/purchaser will have a personalized Health Hero Services Home Page. This win 
allow the purchaser to view: 

• Alert messages 

• Program summary 

.• Sponsor or Health Hero messages lo carogrver/purchaser 

• links to careguide (or other sponsor) web pages/content . 

• Caregiver : selected reports with fax/e^mail/print/view on-line options 

• To physician 

• Other care manager 

• Others 

4.8 Help 

Help for the customer willinclude: 

• On-fine FAQ accessible via Health Hero services home page 

• On-line documentation 

4.9 Customer Service 

On-line e-mail 

• Health Hero support staff respond within 24 hours 

Telephone 

• Health Hero staff for "use of service questions" 

• Call center partner for clinical/health related questions 
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4.10 Long Distance Care Program Content 

The Long Distance Care program could include: 
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Program Content 


Personalized Content 


Nutritional Status (weight, 
appetite, eta) » . 

Wellness Rating Scale 

Medication Compliance 

Monthly Assessment Tool , 

• Quality of Life Tool 


Personal Messaging 
Scheduled (le.: Birthday) 
Reminder Service 
Personal Variables 
Personal Goals 


• ADL 




• IADL 




• Safely 




• Depression 




* Mini Martial ^halnc Fvim 




Personal Hvnionp 


I 


Skin Cam 




Nail Care (Podiatry) 




Sleep 


• 


Safety 




Nutritional. Needs 




Primary, Secondary and 
Tertiary Care 




Loss and Coping 




Social Support 




Urinary Incontinence 




Bowel Function 




Activity 




Financial Status 




Barriers to Compliance 




Tip of the Day 




Trivia 




Motivational 





Reports 
Alerts 



Non Responders 

Significant Change in 
Weight 

Significant Change in 
Wellness Rating 

.Medication Non 
Compliance 

Request for a Call 

individually Selected 
Key Mcators 

Monthly Reports 

/* 

Individually Selected 
Variables 

Statement of 
Nutritional Status 

Report of Medication 
Compliance 

Monthly Assessment 
Tool Findings 

Acknowledgement and 
Alternation of Status 
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Up-Selling Opportunities 
Financial Planning 
Books 

Long Term Care Facilities 

Pharmacies 

Webvan.com 

Support Groups 

Medical Support 

Durable Medical Equipment 



Insurance 

Long Term Care Planning 
Safety Products 
Drug Stores 
Card Game Sites 
Travel 

Online Shopping 
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5 High-Level Design 

The currently envisaged design is a simple thin client web interface for the famti u . 
connects to the current middleware and rtafahoc , u ™° nacB ™ ihe family member that 
from Health Buddies. ^^^£ ^1 con,e "« ™<* manages results 

Since there is nmitedcompe^g J^J Srf L^amclT^ '° *"* aPPte,S - 
porchaser/caregWe, Content J, be c»aTH^^^^^^?? 

5.1 User Interface 

The user interface is determined by the actions that the subscriber needs to n P rfnr m tk 
^«™°»*e'ami*member^^ The 

^nrng fc, to Ine LDC program. These screens allow entry ol current Osers to secure 



Login dialog 



lOTTri 




Includes: 

usemame/paes word input boxes 

now user link - loads form to collect Information on 
new user 

forgot password link - loads form with Instructions for 
colling to gel password — ' 

program descriptions link - loads form with 
descriptions of available programs 

program enrollment link - loads form to capture 
information necessary for enrollment In Individual 
programs 
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S> 3 n,ng op to the LDC program. These screens should include capture of dala re the 
caregiver and .he pa.ienl thai enable shipping el a Heanh Buddy to the patient The 
shoufd accept the family member's credi. card as payment fer the program. The cS5 ca Z 
billmgWrastructurewHIrequire.a link into an e-commwce server creaucard 
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Confirmation e-mai) Is sent to 
new caregivers. 

-* • 


The caregivers demographic, contact, login and 1 
password setup information Is captured. Careqtvera 
can optionally subscribe to newsletter. 


Health Buddy 

USOf 

ffifbfmatlon 


Fprm 


Notification letter Is sent to 
pa (lent 


The Health Buddy users demographic and contact 
Information* captured. Optional information e a pt 
medications, physfcbn, Is captured. 


Health Buddy 
User 

Agreement . 


Health 
Buddy 
dialogue. 




Legal agreement obtained via Health Buddy dialogue. 


AcUvBllon' 


Form 




Allows caregiver to turn on, cancel or upgrade service 


Usei ~ 
Agreement . 


Form 


Caregiver acceptance of 
agreement required to move 
on. 


Legal agreement, disclaimer fs loaded 


BlUlng 






Credit card information captured. Verification and 
vaBdatton achieved via Interface to service. 
Transection logged Ma eCommerce server. 


Fulfillment 


Form 


FedEx EDI Interaction 
completed and e-mailed irom 
FedEx to caregiver generated. 


Captures information necessary for FedEx EDI 
transactions 



Choosing LDC preloaded program, creating personalized messages and scheduling 
preloaded and personatized dialogues. These screens should allow the family member to: 

• Select an LDC program and dialogues based on conlen! that are available in the 
(content) database. 

• Create a message (prompt) that can be scheduled lo play, on the Health Buddy on a 
specific date. These personalized messages can be stored using the patient variables 

• structure. 

• Schedule selected content. This should look like a calendar that ^populated based on 
what LDC preloaded program Is chosen and what personalized messages are created. 
The calendar should be editable. The scheduler/calendar may need to be an applet in 
order to offer the required functionality. Scheduling using the current architecture is a 
major Issue. Please see the section describing some of the issues! 
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Form 




Links to available Health Care Resources Le Druo 
Inlormatlon, "health handbook', etc ' [ 


[Sponsor ; 
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Form 




Caregiver can elect to not have sponsor messages 
show op to patlenl *(seo sponsor below) 


(Variables 


Form 


• 


Allows caregiver to enter pt-specific values Instead of 
defaults set by HHN. 



Chocsmg, scheduling, and viewing reports. These screens w8l provide a. web interface 
for a report menu where previously created reports can be viewed, reports can be run and 
reports can be scheduled to run at defined times. The reporting will require a report server 
on the back end as an additional piece of archilecture. 









Alert Select 


Form 


[receive alerts: e-mail, web. 


Report Select 


Form 


Select Reports from pro-defined IlsL Option fa preview 
[reports. 


RReport Delivery 


Form 




Specify report recipients, delivery mode and 
frequency. 


BAIort and 
Report Viewing 


Form 




Viewing options include 

• Alerts 

• Program summary 

• Sponsor or Health Hero messages lo caregiver 

• Links to careguide (or other sponsor) web 
pages/content 

• Caregiver-selected reports with faxfe- | 
mniVpiint/view on-line options J 



'Creating/scheduling sponsor messages/dialogues. These screens should allow for 
creation and scheduling ol sponsor messages. This may be a screen in a separate wizard . 
that can be run by the sponsor (i.e. Careguidexom or olher third party), or created by Health 
Hero using existing composer functionality. 
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ARPUCABON' 


CONTROL 


VALIDATION/RULE \ (DESOTPnON - i $ - ;c.^^ 


Schedula 
Calendar 


Form 


Schedule LOG program content with appended 
sponsor messages for del/very via Health Buddy Can 
. jba edited. 1 



The design of the user interface will be wizardlike, stepping the caregiver through the above 
actions. The interface will be web based so that no Installation will be required on the client 
machines. M . 11 

The user interface will bo entirely new. Some of the current screens could be used as 
models, but most of the interaction that the subscriber will have with the system will be at a 
simpler level than with the current care managers. The user interf ace will be simple and easy 
for a subscriber to walk through and find what they need 

5.2 Server-side changes: Database and Middleware 

Based on the requirements for the interface,, most of the server-side changes will be in 
scheduling flexibility and the addition of servers/middleware lo handle reporting alerts and e- 
commerce. 



are: 



The key database and middleware actions in the HHN/LDC service 

■ • Construction of surveys from preloaded and personalized dialogues; ready for 
download to Health Buddy with specific dialogues or on specific dates. 

• Handling situation where survey is not answered, Le. queuing of surveys while 
allowing for personalized dialogues to run In the box on a given day. 

• Modifying surveys that have been constructed and are scheduled, to add further 
personalized dialogues. 

» Scheduling constructed surveys to run on Health Buddy. 

• Scheduling reports 

• Running reports and returning results to files that are linked to family member web 
pages. 

« Including graphs in reports. 

• Handling ol role-based securily, archiving and distribution of reports. 

• Handling alerts.. 

This database and middleware functionality requires additional middleware to be written for 
database communication and communication with an additional report server, graphics 
Server and web server. Middleware changes need to be made to allow extra flexibility in 
scheduling. (Please see scheduling section later). 

When reporting Irom the server, the middleware components interact with the database, the 
graphics server, the web server, the report server, and the report writer. There are two 
distinct sets of middleware: those interacting with the web server and those interacting with 
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the report server to create reports. The components used by the web server assist in 
creating dynamic web pages for display to the user. The components used by the report 
server handle the interactions between the graphics server, the database, and the report 
writer to bring all the pieces together into a completed report. 

The middleware components interact with the report writer to construct the reports from 
database data and from graphical and textual output produced by the graphics server. The 
middleware controls the creation of ad-hoc reports with help from the report writer's functions 
Data may be sent from the middleware or from the database to the graphics server. The 
middleware connects to the various databases that are supported in the application. 

Changes to the cunent database should be fairly limited.. There will be multiple additions 
however, since the database will have lo^tore additional information, such as credit card 
data and alert information. A more in-depth review of the requirements will be needed in 
order to list all ofthe database additions and changes. 

The current middleware can be used with additions and modifications to handle the additional 
data and the additional server-side components that are required for reporting and e- 
commerce. 

5.3 Application Content 

In order for this application to be relevant to a wide patient population, a significant quantity of 
high-quality content needs to be developed and integrated into the application. Content areas 
may include: . . " 

• Personal hygiene, skin care, nail care, sleep, safety, social support, urinary 
incontinence, bowel function, activity, financial status, barriers. 

• Nutritional status 

• Medication compliance 
Other key tasks in the content area are: 

• Content needs to be ananged to be readily scheduled into marketable programs e.g. 
rhonlhry, quarterly etc. 

• Content needs to be tagged to enable reporting of results. ~ 

The pre-defined application content will be created by HHN or the service provider using the 
Care Composer. The content will be stored, created, and reviewed using the Care Composer. 
The subscribers might be able to review the content but they will not be able to modify the 
pre-defined content. Personalized messages can be added to the pre-defined content. 
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5.4 Survey definition and scheduling 

Tho current dialogue scheduling architecture has two significant problems in the context of 
HHN/LDC and other applications (e.g. HHN/DMS -Diabetes). 

• There is no way to merge content at schedule time 

• Only one survey per day can be sent to the Health Buddy 

For the HHN/DMS system, we add personalized questions (goals) to pre-loaded surveys 
(education subtopics) by specifying goals as program metrics. We specify one metric that 
sets an upper limit on the number ol goals allowed and Individual metrics for each possible 
goal Questions based on these metrics can then be added to each preloaded survey 
(pfbgrammatically). These questions act as placeholders for goal questions that may be 
asked at some point in time. 

The architecture described above will work for the HHN/LDC application only if we ensure 
that some pre-loaded content Is sent to the Health Buddy each day. Even then, if questions 
are not answered on a given day, surveys scheduled for the next day will not be sent on that 
day. the current architecture thus does not ensure that personalized content scheduled for a 
specific day will actually run. The best we can do in the current architecture is to allow 
personalized messages to be appended to dialogues that are part of the program, and for the 
program dialogue and message appendix to be run in sequence. However there would be no 
guarantee that a personalized message would appear on a particular day of the year. 

Going forward, a more flexible architecture is desired Features and requirements should 
include: 

• Ability to combine surveys for scheduling on a given day. 

• Ability to schedule surveys like appointments e.g. weekly, monthly etc. via a 
calendar. 

The scheduling of personalized content is one area where a lot of work will need to be done 
to give the flexibility requested in the requirements. There are some workarounds as 
described above, but the flexibility desired in the requirements would not bo completely 
attainable with the current scheduling and addition of content mechanisms. Note that all 
additional work on content scheduling would need to be done by, or in conjunction with, the 
HHN Mountain View Engineering team. . . 
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5.5 Reporting 

The reporting component is a crucial part of the HHN/LDC. Subscribers need to easily 
schedule and view reports. The current system does not handle the reporting ariSS 
that will be needed for this system. -rcniiecwre 

The simplest, cleanest approach to reporting is to set up a new report server (with report 
writer), stallstlcs/graphfcs server, and a web server. The report server will require 
middleware for connectivity to the transactional database at EDS and for connectivity with the 
report writer, statistics/graphics server, and the web server. 

Given the current HHN internal processes it would be most efficient for this project (and for 
trie V2.0 core offering) to set up separate boxes for a report server (with report writer) 
statistics/graphics server,, and web server. These boxes would be set up and managed 
internally at HHN and communicate with the EDS data center only for pulllnq data from the 
transactional database as required. . 

The HHN/OLS v2.0 core reporting framework currently under discussion Is highly consistent 
with the reportmg requirements for HHN/LDC. As such, work on HHN/LDC and HHN/OLS 
v2.0 needs to be synchronized. In particular, requirements and design for the reporting 
component of HHN/OLS V2.0 need to be defined before any work on the reportinq 
component of HHNVLDC is done. HHN Software Products has a Preliminary High-Level 
Requirements and Design document for HHN/OLS vZO Batch Reporting. That document is 
currently in circulation within HHN Engineering. 

Since the reports will consist of text and graphs, there needs to be some way to combine 
these items and also produce the graphs without a user interface interaction: For this and 
other reasons, it is suggested that the reports be produced in PDF. PDF format is 
widespread and makes it easier to control layout than with HTML and other formats. With 
PDF, the report will be read-only and accessible from a variety of systems. 

The following section describes a reporting architecture that provides significant scalability 
and workflow efficiencies. The architecture will allow subscribers to automate report 
generation and distribution. The following sections are consistent with the Preliminary High- 
Level Requirements and Design document for HHN/OLS v2.0 Batch Reporting, and the 
reader is referred to thai document for additional detail. 

5.5.1 Reporting Architecture 

The proposed reporting architecture is based around a thin client web-browser user 
interface. The user interface displays a list of reports and enables reports to be 
scheduled or interactively run: Report results are automatically archived and managed In 
a hive, are available lor viewing via role-based security, and can be automatically sent to 
other people as appropriate. 

The server-side architecture is asynchronous whereby a user connects, requests a 
report, and can either wait for the report or disconnect and get the report later. The 
asynchronous design provides more scalability since reports can be queued and 
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processed by the report server. Tho asynchronous architecture also handles problems 
• that could occur with someone on a bad connection; if the connection gets dropped the 
report will bo waiting when they get reconnected. The report server allows for' the 
scheduling of reports , if those reports are run on a consistent basis. 

The central points of action in the architecture are the middleware components, which 
act as traffic cops handling interactions between the other components! The middleware 
components use the report writer to create reports that are sent back to a web page. The 
middleware handles getting data and analyses from the stalistlcat/graphicaJ engine and 
publishing the data or sending the output to the report writer. 

The report writer allows for creation of report templates that can be easily modified at 
njntime to handle the ad-hoc nature of report options. The report writer handles the 
creation of the reports and the export of reports in various file formats. On the server- 
side, the report server uses the middleware and the report writer to process reports that 
are returned to the web server When running reports on the server, the web server 
handles an user Interaction with the server. 

A report server is needed to manage the security, scheduling, and distribution of reports. 
There are available products that suit the needs of HHN applications without HHN having 
to build a report server. Currently, Report2Web has been reviewed. Others currently 
being reviewed are Brio.Report, Actuate, and WebFocus. The main purpose of the report 
server is to manage reports so that users can request reports, retrieve therri later, and 
rerun reports using saved settings. On the web server, a user's security level determines 
the reports a user can run. The report server allows a user access to only the reports 
that the user ran or ones in "public* folders. The report server processes reports 
requested by users via the web server. The parameters and other report information are 
read from the web server and used to create the desired report with the correct options, 
The report server interacts with the middleware components to create reports using the 
report writer components and output from the statistical/graphical engine. 

The statistics/graphics server manages sessions in which specillc graphical analyses 
are run depending on the required reports and personal data. Currently, StatServer from 
MalhSoft has been evaluated. This readily handles the data analysis sections of reports, 
creating graphs or data sets for display in reports. The database system is currently an . 
Oracle database at EDS. _ . 

When the user selects a report, chooses options, and submits the report, the middleware 
. handles the interaction with the statistics/graphics server. For example, an instance of 
the statistics/graphics engine is created via its Open method, and a new analysis object 
is created. Then, arguments and data associated with the analytic used are passed to 
the analysis. After this, the Run method for this analysis object is called. The results are 
returned, to a Hie. which contains the information relevant to the report. The Image and/or 
summary statistics is then embedded Into the report by the middleware. 
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5.6 E-Commerce and Fulfillment 

A summary of E-commerce servers is provided as an appendix For th» mum, ~, 
app.tea.ioo a. «rs, biush. we think «^do^JS2^Ji2^- 
would need to be nvestigated'-further in association with 

commerce requirements. d ™» anticipated future 

Fulfillment will involve interaction with the FedEx system currentiv in rw^„ 
understand ir. an API to the FedEx EDI factory £ SSS ZST^&Z 
programmaHcally configure transactions and exchange transaction components 

The FedEx ED! interaction may look like the following: 
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JSJ^ 1 ^ 00 appJ,ca,ion development will need to stay close to development in the 
redfcx fulfillment system and to integrate accordingly. 
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.5.7 Overall Design Issues 

Il ls, envisaged that HHN/LDC would address the requirements described above through a 
new thin client web user interface that facilitates communication with- the Health Buddy via 
the HHN/OLS. The selected content topics would be finked to dialogues in the Data Center. 
These would then be run remotely over the Heailh Buddy appliance. This thin client user 
interface would also communicate with a report server, graphics server, and web server that 
would pull data from the HHN/OLS Data Center, run reports, and link reports to the family 
member's web page. 

Many of Ihe architectural issues discussed herein are currently being discussed by the HHN 
Architecture team. Some of these issues, while specific to the LDC project, apply more 
generally to a more flexible next generation HHN/OLS system, in particular, the architecture 
described above would provide a flexible, asynchronous, server-side reporting system for the 
core system. The scalability and the asynchronous nature of Ihe proposed reporting 
architecture will provide a fast user experience while managing demands on server 
resources. The major areas that need improvement lor this project are more dynamic 
scheduling of content and reporting/alerting of users. 
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6, 1 Key Business Analysis Considerations 

Caregulde.com 

The case for developing this product lies in the potential business relationship with 
Careguide.com. .Specifically, given thai Ihls Is. a serious opportunity, an HHN team needs to 
meet with Caregulde.com in order to gain an understanding of: 

• Careguldexom's current product and product development milestones 

• Key goals and requirements of this application from Careguide. corn's perspective 

• How and where the project wfll provide profits to HHN and to Careguidacom 

• Risks for Careguide.com and HHN 

• Who will own and develop ancillary business opportunities 



6.2 Software Lifecycle Development 

HHN Software Products has the following phased software lifecycle development process: 

1 . High level requirements and design 

2. Detailed design 

3: Development stage 1 

4. Deployment as beta 

5. Development stage 2 

6. Commercial deployment 

Typically phase 1 takes one to two months, depending on availability of solid requirements 
and phase 2 takes, approximately two months. Milestones and schedules for stages beyond 
this can not be determined until the detailed design is in place. 

The development of the HHN/LDC system will have to closely follow the other changes being 
made in the core HHN system. Many of the major changes required to make the HHN/LDC 
successful are in discussion as changes to the core system. The HHN/LDC requirements will 
be helpful in defining changes that need to be made in the core system, changes that will 
assist in the development of the HHN/LDC service going forward 
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6.3 Next Steps 

Slfrl f h C h are9 " id9C0m neod ,0 bo lo developing an understanding of .he 

potential relationship, the* current product and product development milestones and kev 

goals and requirements ol this application from careguldexom's perspective. ' 

Conditional on the business case and interest, the following internal resources and activities 
are required: awniw> 

1. HHN Software Products Involvement. HHN Software Products to meet with 
careguide.com in order to begin a software business analysis and soltware 
requirements/design process. Some Issues involved In this process are addressed 
g above. This work would result in a Detailed Design document for the software build. 

Z HHN Marketing Involvement. HHN Marketing to develop a concept document and 
a marketing requirements document for this project. 

3. HHN Clinical Involvement. HHN Clinical Department to contribute to the conceot 
document, the MRQ, and the Delated Design document. 

4. HHN Engineering Involvement HHN Engineering lo bo involved in any changes to 
the current middleware and Care applet functionality as described abdve. 

5 ' " H 1 NQ A ,r,v . 0,veme "'- HHN OA to be Involved in testing and deploying any system 
buffl, and estimates ol their time would need to be Included in any project plan. 



6. 



HHN Supply Chain Involvement. HHN Supply Chain to be involved in setting up 
the eCommerce server and the fulfillment and billing processes. 
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Appendix: E-Commerce Servers 

E-Commerce servers come in four broad classes: 

Web Storefronts are shrink-wrapped calaJoa products that onohi« • . . 
a web browse, They «yP^de^ 

payment system. Additional functions include catalog builders search S?k 3 
carts, and order tracking. No gateways or APIs to legacy ba^ uJZ e T 
support, or inventory systems are usuaHy provided. Links aTe S"o S 1 ^ 
screen-scraping, and flat data. Web storefronts typically rSoTf^ } 'T 9 ' 
platforms and are priced in the range $100oTSSo Ve^o! .T! 
Net.Commerce ^^^^ 

°Pen Market 

Integrated Web Catalogs are shrink-wrapped customizable storefronts, with shoppino 
carts, customer-specific pricing abilities, customer account management Zk7ns and 
product sales reporting; Additional functionality deludes messade basel TT^r.ll 
scraping links to inventory and accounUng systems. M^teSL^ZrZT 
on NT and UN.X pladorms and are prfced k, the rangfCoo TSToSTJZ 
.nclude CommerceOne (www.commBrcPonp rnm) ciarus (www clan™™ I , ! 
Ariba (www.arlba.cnrn/™,^^ (™ ™xlam S corp. C or n), and 

^Z^oZm^c 9 , C TT ^ P,09rammi "9 toots that enable users and 
integrators to EC functional serves with gateways or. APIs to backolfiro 

apphcauons. Features inc.ude shopping carts, cos.omer-s/ecitte product j£t£ ' 

llT^Tl^? abi,i,les - and cus,omer accoum man « <« 

sender tool sets typ, ca »y run on NT and UNIX platforms and are priced In the rande 
server, Oracle, and Procurenet (www.procurenel.comT 

stomEr.^ f!T efS ^ "° n ^^PP^. customized solutions incorporating 
storefront Integrated catalog, and server tools with robust, object-oriented APIs and 

ss *r pe ;r 9acy ec 3ys,ems - En,erprise w ° b -o„^ 

cl,^l P a " d 3,6 PriCed h ,he 13099 $50 - 000 *° teOOMO. Vendors include 

connect (wwvyxgnnecH^^ and Broadvlsion (www.broadvislonrnm) 
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